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DISPOSITIF DE TRAITEMENT DE LINFORMATION COMPRENANT DES MOYENS POUR GERER UNE 
MEMOIRE VIRTUELLE, ET PROCEDE DE STOCKAGE D'INFORMATIONS ASSOCIE. 

_ L'invention concerne un dispositif de traitement de I'in- 
formation (20, 22) comprenant des moyens de traitement et 
des moyens de memorisation principaux, caracterise en ce 
qu'il comprend: 

- des moyens pour detecter que les moyens de memori- 
sation principaux contiennent une quantite d'informations 
telle qu'un stockage supplemental d'un ensemble donne 
d'informations a stocker (J) n'est pas possible; 

- des moyens pour seiectionner, dans les moyens de 
memorisation principaux, un ensemble d'informations a de- 
charger (K) pour liberer dans les moyens de memorisation 
principaux un espace autorisant le stockage dudit ensemble 
d'informations a stocker; 

- des moyens pour decharger I'ensemble d'informations 
a decharger (K) dans des moyens de memorisation secon- 
dares (23 a 25), dans le cas ou ces moyens ne contiennent 
pas ledit ensemble d'informations a decharger; et 

- des moyens pour stocker dans les moyens de memo- 
risation principaux I'ensemble d'informations a stocker (J). 

L'invention concerne aussi le precede associe. 




Illllllllllllllllllllllllllllllllllllllllllll 

5>777673At f > 



2777673 

Titre : 

Dispositif de traitement de Tinformation comprenant des moyens pour g6rer 
une m6moire virtuelle, et precede de stockage d'informations associe 

5 La pr§sente invention concerne un dispositif de traitement de 

reformation presentant une memoire de taille limitee, et agenc§ en 
consequence pour effectuer une gestion optimale de cette m6moire. Elle 
concerne done en particulier la carte a microprocesseur ou equivalent. 

10 Depuis une vingtaine d'annee, ce type de cartes prend une 

grande place dans la vie courante. Le domaine bancaire s'est interess6 le 
premier aux cartes a microcircuit : leur principal avantage est de diminuer la 
fraude. Les societes de television a peage et de radiotelephonie les utilisent 
comme moyen de generation des des qui servent a chiffrer et dechiffrer des 

15 emissions crypt6es. Pour garantir la securite, il a fallu cr6er une nouvelle 
architecture de circuit integre. Les cartes de type porte-monnaie 
6lectronique contiennent une somme d'argent electronique ; d'autres cartes, 
dites de fidelite, procurent des avantages financiers a leurs proprietaires. 

20 On le voit, les appareils en relation avec des cartes £ microcircuit 

et plus particulidrement les cartes a microprocesseur, sont utilisables dans 
un nombre de plus en plus grand d'applications. Au debut, le systeme 
Sexploitation des cartes, e'est a dire le programme situe en memoire ROM, 
ne pouvait gerer qu'une seule application. Le systeme d'exploitation est 

25 inscrit au moment de la fabrication du micro-circuit. En augmentant la taille 
de la m§moire programme (ROM) et de la memoire programmable non 
volatile (EPROM et EEPROM, de nos jours FeRAM), le systeme 
d'exploitation peut executer davantage de fonctions. Mais le nombre de ces 
fonctions est toujours limite par la taille de la memoire ROM. De plus, le 

30 rajout d'une fonction supplementaire dans la ROM implique de r6aliser un 
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nouveau masque ; cette realisation coute tres cher et rVest veritablement 
rentabilisee que si une grande quantity de cartes sont concern6es. 

Un moyen d'augmenter !e nombre de ces fonctions sans toucher 
d la m6moire ROM consiste a ecrire dans la m§moire programmable, du 
programme executable ainsi que des donn6es permettant de le faire 
fonctionner. II est ainsi possible de rajouter des fonctions suppI6mentaires a 
un syst&me d'exploitation qui ne possede au depart qu'un nombre fige de 
fonctions. La demande de brevet FR-A-2.748.134 decrit un moyen de 
charger du programme dans la memoire programmable. Mais la memoire 
programmable est d'une taille limitee : une fois remplie avec un programme, 
il n'est plus possible de rajouter de fonctions. De plus, le stockage de ce 
programme s'effectue au detriment de la place memoire destinee aux 
donndes dans la memoire programmable. Le precedent proc6de s'utilise 
pour corriger certaines imperfections du programme situe en ROM ou pour 
rajouter quelques autres fonctions. Si une carte doit ex6cuter un programme 
d'une taille tres importante, le proced6 d6crit dans ce document peut 
s'averer insuffisant. 

20 La presente invention a pour objet de resoudre ce problfeme en 

proposant une methode de chargement et dechargement de la memoire 
programmable en fonction des besoins en ce qui concerne les programmes 
et/ou les donnees applicatives, pour un dispositif de traitement de 
Tinformation dont la memoire est de taille limit§e f comme par exemple celle 

25 d'une carte. Ainsi dans le cas de la carte, il devient possible a celle-ci 
d'executer des applications tres diverses telles que : Porte-Monnaie 
Electronique, application bancaire, t§l§phonie GSM ou application sante 
actuellement experimentee en FRANCE. A I'aide de la presente invention, 
les applications qui viennent d'etre enumerees sont virtuellement dans la 

30 carte. Le propri6taire de la carte les a charg6es au prealable ; ainsi, la carte 
est configur6e selon ses propres besoins. 



10 
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La pr6sente invention permet aussi de resoudre un autre 
probleme. Un utilisateur peut avoir besoin d'ouvrir en meme temps deux fois 
une m£me application. L'execution de cette application dans un dispositif de 
traitement de reformation tel qu'une carte dure un certain temps. Pour 
accelerer le traitement, it est avantageux de pouvoir commencer une 
seconde ex6cution duplication avant la fin de la premiere. Ainsi, le meme 
programme se d6roule deux fois en meme temps. 

Plus g§neralement, la presente invention peut 6galement s'utiliser 
dans le domaine des dispositifs de traitement de reformation, autres que 
des cartes, dotes de ressources memoire limitees. Ces dispositifs sont 
dotes de moyens de communication avec le reseau et, utilisent 
eventuellement la carte £ microprocesseur comme moyens de controle et de 
memorisation de codes de securite. 

Le but est atteint par le fait que le dispositif de traitement de 
reformation concern^ est dote d'un systeme d'exploitation comprenant au 
moins trois fonctions : 

- Chargement d'informations applicatives. 

- Dechargement d'informations applicatives. 

- Execution d'informations applicatives. 

Pour acquerir une nouvelle application, le dispositif de traitement 
de reformation revolt des informations applicatives dans sa m6moire 
programmable et contrdle ces informations. 

Lors d'une commande regue d'un lecteur cooperant avec le 
dispositif de traitement de I' information en vue d'executer une application, le 
systeme d'exploitation du dispositif analyse le contenu de sa m6moire et 
determine s'il y a lieu d'appeler le reseau pour decharger une partie de sa 
memoire, et/ou de recharger des informations applicatives precedemment 
dechargees. 
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Lors du rechargement conformations applicatives, le systeme 
d'exploitation du dispositif verifie que les informations chargees ont et6 
validees par elle dans le passe. Ces informations sont ensuite executees. 

5 Le reseau peut etre considere comma une extension de la 

memoire programmable du dispositif de traitement de reformation celui-ci y 
envoie ce qu'il ne peut garder dans sa propre memoire. II contr&le, lors du 
rechargement, que les informations regues du reseau sont bien celles qu'il 
avait pr6alablement envoy6es. La memoire ROM du dispositif de traitement 

10 de reformation doit disposer d'un mecanisme de gestion de la memoire 
programmable qui lui permet de charger et d'executer un nombre illimite 
d application. Des lors, les tallies des m£moires ROM et programmables du 
dispositif de traitement de reformation ne sont plus une limitation au nombre 
duplications ex6cutables, et il n'y a plus besoin d'effectuer un nouveau 

15 masquage lors du rajout duplications. 

En resume, linvention concerne un dispositif de traitement de 
reformation comprenant des moyens de traitement de reformation et des 
moyens de memorisation de reformation principaux, caract6ris6 en ce que 
les moyens de traitement comprennent : 

20 

- des moyens pour detecter, au cours du fonctionnement du dispositif 
de traitement de reformation, que les moyens de memorisation principaux 
contiennent un volume d' informations tel qu'un stockage supplemental 
d'un ensemble donne d'informations a stocker n'est pas possible ; 
25 - des moyens pour s§lectionner, dans les moyens de memorisation 

principaux, un ensemble d'informations a decharger, dont le dechargement 
peut liberer dans les moyens de memorisation principaux un espace 
suffisant pour autoriser le stockage dudit ensemble d'informations & stocker 

30 - des moyens pour decharger r ensemble d'informations a decharger 

dans des moyens de memorisation secondaires, dans le cas ou lesdits 
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moyens de memorisation secondares ne contiennent pas ledit ensemble 
d'informations £ d§charger ; et 

- des moyens pour stocker dans les moyens de memorisation 
principaux Tensemble d'informations a stocker. 

5 

L'invention concerns aussi le procede associe. 

D'autres details et avantages de la pr6sente invention apparaTtront 
au cours de la description suivante de quelques modes d'execution preferes 
10 mais non limitatifs, en regard des dessins annexes sur lesquels : 

La figure 1 represente un reseau de traitement de donnees utilise 
par l'invention ; 

La figure 2 represente un dispositif de traitement de reformation, 
utilise dans la figure 1 et cooperant avec une carte a puce ; 
15 La figure 3 represente une variante de la figure 2, dans laquelle le 

dispositif de traitement de I'information intfegre les fonctionnalites de la carte 
a puce ; 

La figure 4 est une variante de la figure 2, ou le dispositif de 
traitement de I'information est equipe d'un dispositif de lecture d'une piste 
20 optique ; et 

La figure 5 represente une variante de la figure 3. 

Sur la figure 1 , un terminal 20, apte £ lire une carte a puce , ou un 
terminal 22 integrant des fonctionnalites de carte a puce cooperent avec des 

25 banques de donnees 23 a 25 distantes et reliees £ ceux-ci par un reseau de 
communication de donnees 26. Le reseau de communication de donnees 26 
est notamment un r6seau tdlephonique, le r6seau Internet, ou tout autre 
reseau de communication de donnees. Chaque banque de donnees 
comprend une unite centrale de traitement de donn6es g<§rant une m§moire. 

30 Selon l'invention, et comme precise ci-apres, la carte 21 ou le terminal 22 
peuvent, lorsqu'ils d6tectent que le chargement d une nouvelle application 
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dans ceux-ci n'est pas possible en raison d un manque de place m§moire , 
decider de decharger vers une des banques de donnees 23 a 25 une autre 
application. Ce d6chargement lib£re un espace memoire suffisant pour 
accueillir la nouvelle application. Si la carte 21 ou le terminal 22 ont 
5 ult6rieurement besoin de Tapplication dechargee, ils enverront une 
commande a la banque de donnees correspondante pour recharger 
1'application , apres avoir, le cas echeant Iiber6 a nouveau de la place 
memoire par un d6chargement d'application. 

10 La constitution du terminal 20 et de la carte 21 est precis&e sur la 

figure 2. Le terminal comprend de fa^on connue en soi un microprocesseur 2 
auquel sont relies une memoire ROM 3, et une memoire RAM 4, des moyens 
5 pour cooperer, avec ou sans contact physique, avec la carte a puce 21, et 
une interface de transmission 7 permettant au terminal de communiquer avec 

15 le rgseau de communication de donnees 26 de la figure 1. Le terminal 20 
peut en outre fetre equipe de moyens de stockage tels que des disquettes ou 
disques amovibles ou non, de moyens de saisie (tels qu'un clavier et/ou un 
dispositif de pointage du type souris) et de moyens d'affichage, ces differents 
moyens n'etant pas repr6sentes sur la figure 2. 

20 

Le terminal peut etre constitue par tout appareil informatique installe 
sur un site prive ou public et apte a fournir des moyens de gestion de 
Tinformation ou de delivrance de divers biens ou services, cet appareil 6tant 
installe a demeure ou portable. II peut notamment s'agir aussi d'un appareil 
25 d6die aux telecommunications. 

Par ailleurs, la carte 21 porte une puce incluant des moyens de 
traitement de reformation 9, une memoire non volatile 10, une m§moire 
volatile de travail RAM 14, et des moyens 13 pour cooperer avec le terminal 
30 20. Cette puce est agenc6e pour definir, dans la memoire 10, une zone 
secrete 11 dans laquelie des informations une fois enregistr6es, sont 
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inaccessibles depuis I'ext6rieur de la puce mais seulement accessibles aux 
moyens de traitement 9, et une zone accessible 12 qui est rendue accessible 
depuis Texterieur de la puce par le microprocesseur 9 pour une lecture et/ou 
une 6criture d'informations. Chaque zone de la memoire non volatile 10 peut 
5 comprendre une partie non modifiable ROM et une partie modifiable EPROM, 
EEPROM, ou constitute de memoire RAM du type •flash" ou FRAM (cette 
dernidre 6tant une m6moire RAM ferromagnetique), c'est-a-dire pr6sentant 
les caract6ristiques d'une memoire EEPROM avec en outre des temps 
d'acces identiques a ceux d'une RAM classique. 

10 

En tant que puce, on pourra notamment utiliser un 
microprocesseur autoprogrammable a m6moire non volatile, tel que d6crit 
dans le brevet americain n° 4.382.279 au nom de la Demanderesse. Comme 
indiqu6 en colonne 1, lignes 13-25 de ce brevet, le caractere 

15 autoprogrammable de la puce correspond a la possibility pour un 
programme fi situe dans une memoire ROM, de modifier un autre 
programme fj situ§ dans une m§moire programmable en un programme gj. 
Dans une variante, le microprocesseur de la puce est remplace - ou tout du 
moins complete - par des circuits logiques implantts dans une puce a semi- 

20 conducteurs. En effet, de tels circuits sont aptes a effectuer des calculs, 
notamment d'authentification et de signature, grace a de I'electronique 
cablee, et non microprogrammee. lis peuvent notamment etre de type ASIC 
(de I'anglais « Application Specific Integrated Circuit »). A titre d'exemple 
d ASIC, on peut citer le composant de la soci6te SIEMENS commercialis6 

25 sous la r6f6rence SLE 4436 et celui de la societe SGS-THOMSON 
commercialisd sous la reference ST 1335. Avantageusement, la puce sera 
con$ue sous forme monolithique. 

Une variante de la figure 2 est illustr6e sur la figure 3, ou le 
30 terminal 22 de la figure 1 comprend. outre les elements du terminal 20, ceux 
de la carte 21 disposes dans un module 15, les elements communs aux 
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deux figures 2,3 portant les m§mes references. Toutefois, les moyens de 
cooperation 5,13 de la figure 2 sont remplac6s par une liaison permanente 
entre le microprocesseur 2 et le microprocesseur 9. 

Une variante de la figure 3 est representee sur la figure 5. Ici, le 
terminal 50 ne comprend qu'un seul microprocesseur 51 ou equivalent , relie 
£ une m6moire RAM 52 et a une memoire non volatile 53. La memoire non 
volatile 53 comprend une zone 54 rendue accessible de J'exterieur du 
terminal par le microprocesseur 51, et une zone secrete 55 accessible 
seulement au microprocesseur 51. Le microprocesseur 51 possede la 
caracteristique autoprogrammable du microprocesseur 9, decrite en relation 
avec la figure 2. Enfin, le terminal 50 possede une interface de transmission 
56 lui permettant de communiquer avec le r6seau de communication de 
donnees 26 de la figure 1 . 

La description qui suit fera reference, de fagon non limitative, a la 
forme de realisation de la figure 2 et le terminal 20 sera denomme 
« lecteur » en raison de sa fonction lecteur de la carte 21 , mais il est clair 
que cette description se transpose a la forme de realisation de la figure 3 ou 
de la figure 5. Sur la figure 3 t le module 15 aura les memes fonctionnalites 
que ceiles de la carte 21 de la figure 2. 

Les memoires de la carte sont organisees de la fagon suivante : 
une memoire de type ROM, une memoire de travail de type RAM, et une 
25 memoire programmable non volatile de type EEPROM ou FLASH. Comme 
represente sur le tableau 1 , la memoire ROM contient une zone de systeme 
d'exploitation de base comprenant au minimum des sous-programmes ou 
routines telles que celles d'entree/sortie et d'ecriture/lecture en memoire et 
une zone de systeme d'exploitation d'une m6moire virtuelle, cette rn6moire 
30 virtuelle etant constituee par la m6moire des banques de donnees 23 a 25. 
Le systeme d'exploitation de base et le systeme d'exploitation de la memoire 



10 



15 



20 



NSDOCID: <FR 2777673A1 \ > 



2777673 

9 

virtuelle forment ensemble ce que Ton appellera par la suite le « systeme 
Sexploitation de la carte ». 

Le systeme d'exploitation de la memoire virtuelle est capable de 
gerer de preference au moins neuf commandes. Quatre commandes au 
moins sont Ianc6es par le lecteur vers la carte : 

- Chargement duplications en carte. 

- Execution en carte des applications pr6c6demment chargees. 

- Effacement d'applications en carte. 

- Controle de presence d'applications en carte. 
Cinq autres commandes sont Ianc6es par la carte vers le lecteur : 

- Dechargement d'applications vers le reseau . 

- Rechargement d'applications depuis le reseau. 

- Suspension du processus de chargement . 

- Reprise du processus de chargement. 

- Effacement d'applications dans le reseau. 
Dans une realisation particuliere, le systeme d'exploitation de la memoire 
virtuelle filtre et transmet au programme de Tapplication charge en memoire 
programmable, tous les ordres regus de I'exterieur qui doivent etre traites 
par ce programme. 

Dans le present texte, le terme « information » designe tout 
programme executable ou donnee non executable en general. Le terme 
« application » designe un programme particulier, destine a mettre en 
25 oeuvre une application d'un fournisseur de services ou de produits, et des 
donnees d'application associees.. 

Toujours selon le tableau 1 , la memoire programmable comporte 
au minimum trois zones : 

-une premiere zone dite u des donn6es de systdme n contenant un code *C" 
30 identifiant la carte ; 
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-une seconde zone dite « de donnees de gestion » contenant des donnees 
de gestion des applications , a savoir une cle de signature dite a SWAP " 
particulfere £ chaque carte, une ou plusieurs cl§s de chiffrement liees selon 
le cas £ des fournisseurs duplications ou a des applications particulieres, 
5 et un tableau appel§ u TAB_APPLI \ et 

-une troisieme zone dite « de chargement », utilisee pour recevoir les 
informations duplications, c'est-a-dire du programme executable et/ou des 
donn6es n§cessaires au fonctionnement de ce programme. 

10 Au depart, la carte peut etre donnee a son porteur avec une zone 

de chargement et un tableau TAB_APPLI vides. Au moins la cl§ SWAP est 
situ6e dans la zone secrete 11 de la memoire non volatile 10 de la carte. 



Zone de chargement des informations duplications 



Zone des donnees de gestion (SWAP, TAB_APPLI, ..) 
Zone des donnees de systeme (code C ) 



Zone du systeme d'exploitation de la memoire virtuelle 

(ROM) 



Zone du systeme d'exploitation de base 
(ROM) 
Tableau 1 

15 

Le tableau TAB_APPLI contient les informations correspondant 
aux applications disponibles dans la carte, soit que ces applications sont 
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physiquement contenues en carte , soit qu'elles sont virtuellement 
contenues en carte car dechargees vers le reseau II a la structure suivante : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


Tapplication 


stockage 


d'octets 


des informations 


Dechargement 


I 


ADR-I 


I 


SGNM 


Charge 


J 


ADR-J 


m 


SGN-J 


Decharge 


K 


ADR-K 


n 


SGN-K 


Charg6 



Tableau 2 : TAB APPLI 



5 

Le tableau TAB_APPLI 2 comprend autant de lignes que duplications 
rendues disponibles par la carte et, pour chaque ligne, cinq colonnes. Une 
premiere colonne definit un code d'identification I.J.K de I'application. Une 
deuxieme colonne definit une adresse de stockage ADR-I ( ADR-J,ADR-K £ 

10 partir de laquelle I'application est stockee en carte. Une troisieme colonne 
definit un nombre d'octets representant la quantite d'informations de 
rapplication. Une quatridme colonne d6finit une signature portant sur 
Tensemble des octets de Tapplication , calculee en utilisant un algorithme et 
la cle SWAP de la carte en tant que cle secrete. En tant qu'algorithme , on 

15 peut utiliser un algorithme symetrique tel que le D E S. (de Tanglais Data 
Encryption Standard) ou asymetrique tel que le R.S.A. (des auteurs Rivest, 
Shamir et Adleman) ; avantageusement cependant, il sufTira d'utiliser une 
fonction plus simple, telle qu'une fonction de hachage comme MD5 ou SHA, 
ou une fonction telle que le « ou exclusif », puisque, dans le cadre de 

20 invention , la signature ne sort pas de la carte et se trouve done preservee. 
Enfin, une cinquieme colonne definit si Tapplication concernee est dans un 
6tat « charge » en carte ou « d6charge » dans une banque de donnees. 

Dans un premier temps, un porteur de carte ou un foumisseur 
d'applications desire charger en carte une premiere application ayant un 

25 code d'identification " K". L'execution d'une commande de chargement peut 
hire conditionnee par une authentication de porteur ou de foumisseur 
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cTapplications menee a bien. Le mecanisme d'authentification bien connu en 
soi consiste, pour le porteur ou le fournisseur d'applications, a fournir a la 
carte une information lui permettant de s'assurer qu'elle dialogue avec un 
interlocuteur habtlit§. 
5 La commande de chargement contient un ordre de chargement, le 

code C de la carte, le code K de ('application et le nombre d'octets n 
d' informations correspondant a cette application, ce qui donne le format de 
commande suivant : 



Ordre de Chargement 


Carte C 


Appli K 


nombre n 



10 

Une fois la commande regue par la carte, le systeme 
d'exploitation de la carte v§rifie que le code C envoye est bien le meme que 
celui enregistre dans la zone des donnees de systeme . Dans la negative, la 
carte renvoie au reseau un message derreur. Dans I'affirmative, les 

15 informations de I'application sont done bien destinees a cette carte : le 
systeme d'exploitation de la carte lit alors le tableau TAB_APPLI dans la 
zone des donnees de gestion pour determiner s'il s'agit d'un chargement 
initial ou non. Au depart, TAB_APPLI ne contient pas d'informations sur 
Tapplication K ; si ce n'est pas le cas t la carte n§pond au lecteur par le 

20 message « application deja chargee » ; si e'est le cas, il s'agit done d'un 
chargement initial. Le systeme d'expfoitation de la carte determine si les n 
octets peuvent etre log6s dans sa memoire : dans Taffirmative, elle calcule 
Tadresse de debut tt ADR-K n d'un premier bloc de n octets disponibles dans 
la zone de chargement. Dans la negative, elle renvoie le message 

25 « memoire insuffisante ». Enfin, la carte indique au lecteur qu'il peut envoyer 
les n octets de Tapplication, a I'aide de la reponse w OK_Chargement *. Le 
lecteur envoie alors les n octets de I'application . 

Une fois les informations de I'application stockees en memoire 
30 programmable, le syst&me d'exploitation de la carte calcule la signature 
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« SGN-K » de ces informations. II rentre aiors dans le tableau TAB__APPLI 
le code duplication K ( I'adresse de stockage ADR-K, le nombre d'octets n, 
et la signature SGN-K. Une fois cette operation effectuee, I'indicateur 
u Chargement/D§chargement n est positionne sur ° Charg6 *. La mise a jour 
du tableau TAE3_APPLI 6tant termin6e, le systeme Sexploitation de la carte 
peut alors envoyer un compte-rendu, a travers le lecteur, au porteur de carte 
ou au fournisseur d'applications, indiquant que le chargement de 
rapplication a 6t6 correctement effectue. Le tableau TAB_APPLI poss&de 
alors la structure suivante : 



Code 
de 

rapplication 


Adresse 

de 
stockage 


Nombre 
d'octets 


Signature 
des 
informations 


Chargement/ 
Dechargement 


K 


ADR-K 


n 


SGN-K 


Charge 


Ta 


bleau 3 : TAE 


t APPLI 



Selon une premiere variante, le systeme d'exploitation de la carte 
peut lancer, juste apres le chargement, le programme executable contenu 
dans les informations applicatives, c'est-a-dire dans les informations de 
rapplication. Ceci permet d'initialiser les informations applicatives. Par 
exemple, dans le cas d'une application Porte-Monnaie Electronique, la 
premiere execution du programme permet d'initialiser a 0 Frs le solde du 
porte-monnaie ecrit dans la memoire. Selon une seconde variante, le 
programme executable est lance lors d'une premiere cornmande envoyee 
par le lecteur S la carte et faisant appel d rapplication consid6r6e. De fa^on 
simple, I'adresse de d§but d'execution de rapplication est « ADR-K », mais 
on peut utiliser un adressage indirect : I'adresse designee est alors, de 
fagon connue en soi dans le domaine des microprocesseurs, le contenu de 
la memoire note [ADR-K] qui contient radresse d'execution. 
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Le lecteur envoie a la carte des commandes en specifiant le type 
d'application ; par example, ce type peut §tre code dans le premier des cinq 
octets d'une commande selon la norme ISO 7816-3 ; cet octet est appel6 
dans la dite norme : « CLA ». Le systeme d'exploitation de la memoire 
5 virtuelle de la carte controle les commandes que lui envoie le lecteur et 
determine le code de I'application correspondant a la commande. Puis, il lit 
dans le tableau TAB_APPLI si le code est 6crit ; si c'est le cas, la carte peut 
executer I'application K. Si ce n'est pas le cas, la carte ne peut executer 
I'application K : elle repond en envoyant un message d'erreur. Si le code K 

10 est ecrit dans TAB_APPLI, la valeur de I'indicateur 
« Chargement/Dechargement » est ensuite testee. S'il est positionn6 sur 
« Chargement », les informations applicatives sont bien presentes en 
memoire programmable de la carte. Dans ce cas, le systeme Sexploitation 
de la carte donne la main a un programme de I'application situe a I'adresse 

15 ADR-K ou [ADR-KJ. Nous allons voir par la suite ce qui se passe lorsque la 
m6moire programmable de la carte ne contient pas les informations 
applicatives, parce qu'elles ont deja ete dechargees. 

Supposons maintenant que le porteur de carte ou le fournisseur 
20 d'applications desire que sa carte contienne les informations d'une seconde 
application, notee « J » par exemple. Cela est possible en chargeant les 
informations applicatives « J » dans la memoire programmable de la carte. 
De meme que precedemment, le porteur de carte ou le fournisseur 
d'applications s'authentifie en presentant un secret suivi de la commande de 
25 chargement d'informations applicatives suivante : 



Ordre de chargement 


Carte C 


Appli J 


nombre m 



Elle se presente comme la pr6c6dente relative au chargement de 
I'application K ; ici, le nombre d'octets de I'application est m. 

30 
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Le systeme Sexploitation de la carte verifie le code C et 
recherche le premier bloc de m octets disponible dans la memoire 
programmable. Supposons que la memoire programmable ne peut 
physiquement contenir en meme temps les deux blocs d'informations 
5 applicatives constitues par I'application K et I'application J, mais qu'elle peut 
contenir I'application J si elle decharge tout ou partie de I'application K. La 
carte informe le lecteur qu'elle suspend le processus de chargement de 
I'application J a I'aide d'une commande specifique envoyee au lecteur, et 
decide alors de decharger I'application K dans une banque de donnees qui 
10 peut etre consideree comme la memoire virtuelle de la carte. Ce 
dechargement va liberer de la place memoire pour charger I'application J. 

Le dechargement consiste alors a transferer dans Tune des 
banques de donnees 23 a 25 du reseau destinee notamment a la carte 

15 actuelle, les informations applicatives particulieres a cette carte. Par le 
calcul de signature effectue lors du chargement, la carte est assuree de 
pouvoir contrdler I'integrite et I'authenticite de ses propres informations lors 
d'un rechargement ulterieur. De plus, le fait d'avoir deja effectue le calcul de 
signature lors du chargement initial optimise le temps d'execution de la 

20 commande de dechargement. La carte envoie au lecteur la commande 
suivante : 



Ordre de dechargement 


Carte C 


Appli K 


nombre n 


n octets 


vers le reseau 








d'informations 



Cette commande comporte, comme la commande de chargement, 
25 le code C de la carte, celui K de I'application a decharger ,et le nombre 
d'octets n d'informations de I'application ; elle comporte en plus le contenu 
meme de ces n octets d'informations, transmis au lecteur en meme temps 
que I'ordre de dechargement. Dans le cas ou le dechargement de 
I'application intervient alors qu'une partie de celle-ci a deja ete executee, 
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des informations de contexte, permettant de reprendre utterieurement 
I'execution de I'application a I'endroit ou elle a ete interrompue, sont, soit 
stock§es dans la m§moire programmable de la carte , soit ajoutees aux n 
octets d'informations de I'application et dechargees en meme temps qu'eux 
5 dans le reseau. 

II est possible d'indiquer un identifiant de destinataire sous la 
forme d une adresse de r§seau. Avantageusement, le reseau poss6de une 
table de correspondance qui associe chaque carte a I'adresse de la banque 
10 de donnee qui lui est notamment destinee. Ceci permet d'eviter a la carte 
d'avoir a stocker ladite adresse ou ledit identifiant, et de rassembler dans 
une m§me banque de donnees toutes les informations d6charg§es a partir 
d'une meme carte. 

15 Le lecteur regoit la commande, mais reconnaft qu'elle est destinee 

au reseau : il la renvoie done vers la banque de donnees a laquelle elle est 
adressee. Si le r6seau possede plusieurs banques de donnees, le choix 
peut s'effectuer en fonction du code C de la carte. La banque de donnee 
regoit les n octets d'informations applicatives et renvoie a la carte, via le 

20 lecteur, un accus6 de bonne reception indiquant que le stockage s'est bien 
pass6. La carte modifie alors le tableau TAB_APPLI en positionnant 
I'indicateur Chargement/Dechargement sur u Decharge La place memoire 
occupee jusque-la par les informations applicatives de Tapplication K 
devient disponible. L'operation de chargement de I'application J peut alors 

25 reprendre et la carte envoie au lecteur une commande de reprise du 
processus de chargement ; Toperation de chargement s'effectue de fagon 
identique £ celle de K. Le systeme d'exploitation de la carte determine 
Tadresse de stockage ADR-J des m octets de l application J et indique au 
lecteur par un message « OK_Chargement » qu'il peut envoyer les m octets 

30 d'informations applicatives. 
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Le lecteur envoie les m octets d'informations applicatives qui sont 
Merits a partir de I'adresse " ADR-J ". Une fois les informations de 
I'application J stockees en memoire programmable, le systeme d'exploitation 
de la carte calcule une signature de celles-ci en effectuant un calcul 
5 cryptographique a I'aide de la cle SWAP. Enfin, le systeme d'exploitation 
met a jour le tableau TAB_APPLI en ecrivant le code J, les valeurs ADR-J. m 
et SGN-J, et met a jour I'indicateur " Chargement/Dechargement " en le 
positionnant sur " Charge ". Le systeme d'exploitation peut alors envoyer au 
lecteur un compte-rendu indiquant que le chargement a ete correctement 
10 effectue. 



Le tableau TAB_APPLI possede alors les valeurs suivantes : 



Code de 


Adresse 


nombre 


Signature 


Chargement/ 


I'application 


stockage 


d'octets 


des donnees 


Dechargement 


K 


ADR-K 


n 


SGN-K 


D6charg6 


J 


ADR-J 


m 


SGN-J 


Charge 



tableau 4 : TAB APPLI 



15 

Une fois terminee la mise a jour du tableau TAB_APPLI, le 
systeme d'exploitation de la carte peut alors lancer 1'application J de la 
mfeme fagon qu'il a Ianc6 I'application K et la carte execute la commande 
d'ex§cution que le lecteur lui avait envoyee. 

20 Si le porteur de carte ou le fournisseur d'applications connecte sa 

carte d un lecteur et desire executer une nouvelle fois ('application K, le 
syst6me d'exploitation de la carte analyse le contenu du tableau TAB_APPLI 
pour d6terminer si cette application est accessible avec cette carte. Dans le 
cas present, Tapplication K est bien enregistree dans TAB_APPLI, mais elle 

25 a et6 d6chargee dans le reseau. Une autre application est en m6moire ( e'est 
J et elle occupe m octets. Le systeme d'exploitation teste alors si 
Tapplication K qui occupe n octets en memoire peut §tre charg6e dans ce 
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qui reste disponible en memoire. Comme on l a suppose precedemment, la 
reponse a ce test est negative. Le systeme d'exploitation decide alors de 
decharger I'application J actuelle pour pouvoir recharger I'application K. 

5 La cornmande, emise par la carte, de d§chargement vers le 

r6seau de J est : 



Ordre de dechargement 


Carte C 


Appli J 


nombre 


m octets 


vers le reseau 






m 


d'informations 



L'operation une fois effectuee, I'indicateur de chargement de 
10 I'application J dans TAB — APPLI est mis en position « Decharge ». La place 
memoire etant maintenant disponible, le systeme d'exploitation envoie au 
lecteur une cornmande de rechargement de I'application K depuis le reseau. 
Cette cornmande a le format suivant : 



Ordre de rechargement 


Carte C 


Appli K 


nombre 


a partir du reseau 






n 



15 

Le lecteur regoit la cornmande et la renvoie vers la banque de 
donnee associee a la carte C. La banque de donnee qui possede les 
informations de la carte C regoit la cornmande et recherche dans le fichier 
20 de cette carte, les n octets d'informations applicatives relatives a 
I'application K. La banque de donnees elabore le message suivant, qui est 
la reponse a la derniere cornmande de la carte. Cette reponse est transmise 
a la carte via le lecteur : 



Carte C 


Appli K 


nombre n 


n octets de donnees 



25 



Nsnor.in- <FR 



?777fi7nA1 I > 



2777673 



19 



Le systeme Sexploitation de la carte peut verifier que les codes 
5 C, K et la valeur n re^us, sont bien identiques a ceux de la commande de 
d§chargement 6mise pr6cedemment. Si I'identite est realis6e, la commande 
se poursuit par la reception des n octets de donnees qui sont ecrits a partir 
de I'adresse ADR-K dans la zone de chargement, cette adresse 6tant £ cet 
effet lue par le systdme Sexploitation dans le tableau TAB_APPLI ou 

10 r6cup6r6e £ partir des informations de contexte rechargees. Dans le mfeme 
temps, le systeme d'exploitation calcule la signature des n octets ecrits par 
un calcul cryptographique utilisant la valeur de la cle SWAP. La signature 
recalculee est alors comparee a la valeur ecrite dans le tableau TAB_APPLI. 
Si les donnees revues du reseau ne sont pas identiques a celles 

15 dechargees prec6demment, les deux valeurs de signature ne seront pas 
6gales. II existe alors un doute sur Tauthenticite ou Tint6grit6 des 
informations regues. Les informations chargees ne peuvent done pas fetre 
ex6cut6es. La carte renvoie au lecteur un message d'erreur indiquant une 
reception d'informations erronees au cours de la derniere operation de 

20 chargement, et Timpossibilite d'executer I'application K ; le systeme 
d'exploitation ne met pas I'indicateur de chargement en position « charge » ; 
le cas ech6ant, il peut effacer le contenu de Tapplication K. 

Si en revanche les deux valeurs de signature sont 6gales, les 
25 informations regues correspondent bien a celles de Tapplication K 
prec§demment charg6e dans la carte. Une fois ces controles effectues, le 
systeme d'exploitation de la carte met a jour le tableau TAB_APPLI en 
mettant I'indicateur de chargement de Tapplication K sur la position 
« Charge ». 
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Le tableau TAB APPLI a alors les valeurs suivantes : 



Code de 
('application 


Adresse de 
stockage 


nombre 
d'octets 


Signature 
des donnees 


Chargement/ 
Dechargement 


K 


ADR-K 


n 


SGN-K 


Charge 


J 


ADR-J 


m 


SGN-J 


Decharg6 


Ta 


bleau5:TAB APPLI 



5 Une fois terminee la mise a jour du tableau TAB_APPLI, le 

syst6me d'exploitation lance I'application K comme precedemment, et la 
carte peut executer la derniere commande de type applicative envoyee par 
le lecteur. 

10 On a d§crit pr6c6demment que, lors de la reception par la carte 

d'une commande de chargement d'une application non actuellement 
stock6e, le systeme d'exploitation de la carte teste la place disponible en 
memoire. Si celle-ci est suffisante, le chargement peut s'operer sans 
decharger Tapplication actuellement en memoire. II existe alors deux 

15 applications dans la carte. Le tableau TAB_APPLI prend alors la 
configuration suivante : 



Code de 
I'application 


Adresse de 
stockage 


nombre 
d'octets 


Signature 
des donnees 


Chargement/ 
Dechargement 


K 


ADR-K 


n 


SGN-K 


Charge 


I 


ADR-I 


I 


SGN-I 


Charge 


J 


ADR-J 


m 


SGN-J 


Decharge 


Ta 


bleau6:TAB APPLI 



Dans cet exemple, deux applications I et K co-habitent dans la 
20 carte : elles sont directement ex6cutables. Une troisieme application J est 
accessible £ Paide de cette carte, mais il faut la recharger £ partir du reseau. 
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Les m6moires non volatiles de la carte contiennent les informations 
suivantes : 



ADR-K 

Programme de 
('application K 

Donn<§es 
de I'application K 



ADR-I 

Programme de I'application 
I 

Donnees 
de I'application I 




Donn6es de gestion (cle SWAP, TAB_APPLI,...) 


Donnees de systeme 




(code C .) 




Systeme d'exploitation de la memoire virtuelle 




(ROM) 




Systeme d'exploitation de base 




(ROM) 





Tableau 7 



10 



Ce tableau correspond au tableau 1 precite, dans lequel la zone 
de chargement est detaillee comme suit : on voit que la zone de chargement 
des informations applicatives comprend trois sous-zones : une zone 
recevant les informations de I'application K, une zone recevant les 
informations de I'application I, et une zone residuelle libre qui est de taille 
inferieure £ m. 



A la Iumi6re de cet exemple, on comprend mieux les 
caract£ristiques de Tinvention. La carte est dotee d'un systeme d'exploitation 
15 minimum permettant de gerer la place memoire, de charger ou d6charger 
des applications, de signer les informations applicatives a decharger vers le 
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reseau, de verifier les informations applicatives dechargees et revues du 
r6seau en comparant les signatures, et de lancer des applications chargees 
dans la m§moire. La signature permet de verifier que les informations 
applicatives stockees dans la banque de donnees ont bien ete 
5 pr6alablement charg§es dans cette carte. Le lecteur est dote d'un 
programme qui reconnait les commandes de dechargement et rechargement 
de la carte et de moyens pour transmettre les dites commandes au reseau. 
Enfin, le reseau est 6quip6 de banques de donnees, la memoire de ces 
banques pouvant fetre consideree comme une extension de la memoire 
1 0 programmable de la carte. 

Comme on Pa vu en preambule, I'inscription de routines dans la 
memoire programmable pour modifier le fonctionnement du programme en 
ROM ne peut etre realisee que par des personnes connaissant ce 
programme. Les sauts vers ces routines et leurs retours dans le programme 
en ROM n6cessitent de connaltre precisement les adresses, les parametres 
d'entr6e et de sortie de ces routines, Tutilisation de la memoire de travail, 
.etc. La pr6sente invention resout ce probleme en evitant d'utiliser ces 
routines et, par voie de consequence, de divulguer les specifications de ces 
routines, tout en autorisant Tex6cution de nombreuses applications. Les 
programmes applicatifs s'executent en faisant le moins possible appel au 
programme en ROM. Le concepteur de ce programme peut indiquer les 
points d f entr6e & certaines routines dites elementaires : reception d'octets, 
emission d'octets, ecriture de n octets en memoire programmable, calcul 
cryptographique ...etc. 

Une premiere amelioration de r invention consiste a chiffrer les 
informations applicatives pour les prot6ger lors de leurs diff6rents transferts 
entre le dispositif de traitement de P information destind a accueillir des 
30 applications (tel que la carte 21 ou le terminal 22 de la figure 1 ) et le r£seau, 
et lors de leur stockage en dehors de la carte 21 ou du terminal 22. 



15 



20 



25 
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Un premier chiffrement d'applicatton conceme le chargement 
initial de 1'application par un fournisseur d'applications et utilise une cle de 
base secrete, detenue par le dispositif de traitement de reformation et le 
5 fournisseur dapplications situe dans le reseau ; dans le cas ou le dispositif 
de traitement de reformation est une carte, son lecteur ignore la cle de 
base. Avantageusement, chaque application est chiffree avec une cle 
divers ifi 6 e propre, obtenue a partir de la cl6 de base et d un diversifiant 
constitue par un parametre sp6cifique de I'application , par exemple son 
10 code K ou son adresse de stockage ADR-K dans la memoire programmable. 
Ce diversifiant peut etre stocke dans le tableau TAB_APPLI de sorte que le 
systeme d'exploitation peut facilement le retrouver lors des commandes de 
chargement / d6chargement. 

15 Lors du chargement initial de I'application par le fournisseur 

d'applications dans le dispositif de traitement de Tinformation 21 ou 22, ce 
fournisseur calcule la cle diversifiee associee a cette application et chiffre 
['application au moyen de celle-ci avant de lenvoyer dans le reseau ; a 
reception, le dispositif de traitement de reformation calcule la cle diversifi§e 

20 associ6e a cette application et la dechiffre avec celle-ci, avant de la stacker 
dans la zone de chargement de la memoire programmable. 

Un second chiffrement de I'application concerne les 
dechargements et rechargements effectu6s par le dispositif de traitement de 

25 reformation 21, 22. Lors d'un dechargement de I'application par le dispositif 
de traitement de reformation 21,22 vers une banque de donn§es, 
I'application est £ nouveau chiffree par ce dispositif. La cle de chiffrement 
utilisee n'a pas d fetre partag^e par le dispositif de traitement de ('information 
avec tout autre interlocuteur tel que le fournisseur duplications : n'importe 

30 quelle cle generee par le dispositif de traitement de I'information conviendra, 
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puisque c'est ce m&me dispositif, et lui seul, qui effectuera le dechiffrement 
ulterieur. 

Avantageusement, la carte peut utiiiser le proc6de decrit par le 
5 document US-A-4,907,270 qui a pour objet de fournir un precede pour 
s'assurer de I'authenticit6 et de Tintegrite d'un message chiffre. 

Le chiffrement d§crit ci-dessus permet d'eviter que des 
informations applicatives puissent etre decouvertes par un fraudeur, et 
empeche la copie frauduleuse des programmes applicatifs. 

10 

En plus des commandes decrites precedemment, il est possible 
de prevoir deux commandes supplementaires : une commande d'effacement 
duplications, et une commande de controle de presence ^applications en 
carte. 

15 

La commande d'effacement ^applications consiste, pour le 
porteur de carte ou le fournisseur duplications, £ envoyer a la carte une 
commande destinee a supprimer les applications qui ne sont plus utilisees ; 
son format est le suivant : 

20 



Ordre d'effacement 


Carte C 


Appli K 


nombre n 


duplications 









Elle comprend un ordre d'effacement d'applications, le code C de la carte 
concernee, le code K de Tapplication, et eventuellement le nombre n 
d'octets d' informations de I'application. Si I'application concernee est 
25 chargee en carte . le systeme d'exploitation de la carte rend disponible 
I'espace memoire reserve jusque-la a I'application K. Si en revanche 
I'application K etait dechargee dans une banque de donnees, la carte envoie 
vers celle-ci un ordre d'effacement qui a le meme format que celui ci-dessus. 
Enfin, une fois que I'ordre d'effacement a ete execute, le systeme 
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Sexploitation efface la ligne du tableau TAB_APPLI concernant cette 
application. 



La commande de controle de presence d'applications en carte 
5 peut prendre deux formes differentes. La premiere forme de la commande 
permet au porteur de carte ou au fournisseur d'applications de demander d 
la carte si elle possede une application particuliere ; son format est le 
suivant : 



Ordre de contrdle de 


Carte C 


Appli K 


nombre n 


presence d'applications 









10 

Elle comprend un ordre de contrdle de presence d'applications, le code C de 
la carte concern6e, le code K de I'application, et eventuellement le nombre n 
d'octets d'informations de I'application. 



15 La seconde forme de la commande permet au porteur de carte ou au 
fournisseur d'applications de demander a la carte I'ensemble des lignes de 
son tableau TAB_APPLI , a I'exclusion bien evidemment des signatures et 
6ventuellement du nombre n d'octets et de I'indicateur de chargement. Le 
format de la commande est le suivant : 

20 



Ordre de contrdle de presence d'applications 



Carte C 



Une seconde amelioration de I'invention consiste a ne declencher 
le d6chargement d'une application vers le reseau que lorsque cela est 
n6cessaire. Si, au moment ou il faut Iib6rer de la memoire, I'application 
25 charg6e n'a pas 6t6 modifiee et si le reseau possede d§ja les memes 
informations applicatives de cette application, il n'est pas utile de d§charger 
ces informations. La seconde amelioration a pour objet d'6viter de stocker 
plusieurs fois les memes valeurs d' informations applicatives sur le reseau. 



i 
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Pour mettre en place cette amelioration il faut modifier le tableau 
TAB_APPLI. voici la nouvelle structure : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


Modification 


1'application 


stockage 


d'octets 


des 


Dechargement 










informations 






K 


ADR-K 


n 


SGN-K 


Charge/ 


OUI/ 










Decharge 


NON 



5 Tableau 8 : TAB-APPLi 



On a ajoute une sixieme colonne au tableau, qui contient un 
indicateur note u Modification n , pouvant prendre deux valeurs : Oui ou Non. 
Lors du chargement initial d'une application, Hndicateur est positionne a 

10 " Oui n : cette valeur indique qu'il faut decharger les informations applicatives 
vers le reseau pour lib§rer la place m6moire correspondante. Par contre, 
apres une commande de rechargement a partir du reseau, I'indicateur est 
positionne a w Non ** : cette valeur indique que les informations applicatives 
stock£es en memoire programmable du dispositif de traitement de 

15 reformation (carte 21 ou terminal 22 de la figure 1) sont identiques a celles 
memorises dans la banque de donnees du reseau. Tant que I'indicateur 
reste d « Non », le systeme d'exploitation du dispositif de traitement de 
reformation n'effectue pas de commande de dechargement de Implication ; 
il positionne uniquement I'indicateur de chargement en position 

20 « Decharge » pour qu'une autre application puisse occuper sa place en 
memoire. Uindicateur est positionnS a u Oui n lorsque ron modifie les 
informations applicatives ; par voie de consequence, la valeur de signature 
n'est alors plus exacte : il faudra la recalculer lors du dechargement. 



25 Cette modification peut intervenir dans au moins deux cas. Le 

premier cas est une mise a jour du programme applicatif, soit pour le rendre 
plus performant en rajoutant des fonctions supplementaires, soit pour 
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corriger un defaut. Le second cas arrive frequemment lorsque, dans la 
memoire programmable du dispositif de traitement de I' information 21 ou 22 , 
des donn6es sont rn£!6es au programme applicatif. Par exemple, une 
application porte-monnaie electronique contient a la fois le logiciel pour 
5 gerer les debits et les credits, mais aussi des donnees dont le solde. A 
chaque utilisation, cette valeur evolue generalement et done, I'indicateur 
" Modification " est presque toujours en position M Oui D . 

Ce dernier exemple amene & une troisieme amelioration de la 
10 presente invention. On voit que dans les informations applicatives, existent d 
la fois du programme executable et des valeurs de donnees applicatives 
susceptibles d'6voluer souvent Les moyens decrits dans la troisieme 
amelioration decrite ci-apres permettent de bien separer les deux types 
d'informations. Le dispositif de traitement de Tinformation choisit alors de ne 
15 decharger vers le r£seau que les informations qu'il a effectivement 
modifiees. 

Pour realiser cette troisieme amelioration, il convient de 
perfectionner ('organisation des memoires non volatiles, qui peut se 
20 sch6matiser de la fagon suivante ; 
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Programme 
de I'application 
(m§moire programmable) 



Donn§es 
de I'application 



Donnees 
evolutives 
sequence 1 



Donn6es 
evolutives 
sequence 2 



Donnees de gestion (cle SWAP, TAB_APPLI,. .) en memoire programmable 
Donnees de type systeme en memoire programmable 

(code C, ) 



Systeme d'exploitation de la memoire virtuelle 
(ROM) 



Systeme d'exploitation de base 
(ROM) 
tableau 9 



Le tableau 9 differe du tableau 1 precite par la structure de sa 
5 zone de chargement de la memoire programmable, qui se presente comme 
suit : 



- un bloc relatif a I'application en tant que telle et comprenant deux sous- 
blocs d'informations : 
10 -un bloc relatif au programme executable de Tapplication, note 

« programme de I'application » ; 

- un bloc relatif aux donnees (non executables) evolutives de 
I'application, note « donnees de ('application » ; 

-un certain nombre de blocs de donnees (non executables) Evolutives 
15 correspondant a des executions particulidres du programme executable ; 

ces executions sont appeiees par la suite des « sequences ». Par definition, 
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les donn6es d'une sequence sont temporaires f c*est-a-dire qu'elles ne sont 
utilisees que lors de cette sequence , et pas lors des sequences 
precedentes ou suivantes. C'est ce qui les distingue des « donnees de 
I'application » pr6cit6es, lesquelles sont utilisees durant toutes les 
5 sequences. Sur le tableau 9, deux blocs de donn§es de sequences sont 
repr6sent6s, not6s « donnees evolutives sequence 1 » et « donn§es 
6volutives sequence 2 ». Le role de ces differents blocs d'informations sera 
expliqu£ dans I'exemple qui va suivre. 

10 Pour realiser cette troisieme amelioration, le tableau TAB_APPLI 

est modifie, il possede la structure suivante : 



Code 
application/ 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signatu- 
re 


Charge./ 
Decharge. 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/1 


p-dat 


SGN-dat-P/1 


Charge 


P/2 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/2 


p-dat 


SGN-dat-P/2 


Charge 


J/1 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/1 


j-dat 


SGN-dat-J/1 


Charge 


J/2 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/2 


j-dat 


SGN-dat-J/2 


Decharge 



tableau 10 : TAB_APPLI 

15 

Vis-a-vis du tableau TAB_APPLI 2 pr6cite, ce tableau pr6sente 
les differences suivantes. La premiere colonne specifie, outre le code de 
I'application , le numero « i » de la sequence concernee. Les informations 
traitees le sont en deux groupes : celles relatives au programme executable 

i 

20 et aux donnees de I'application , et celles relatives aux donnees evolutives 
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des sequences. Pour chaque groupe d' informations , on retrouve les quatre 
colonnes suivantes du tableau TAB_APPLI 2 : adresse de stockage f 
nombre d'octets , signature , indicateur de chargement Chaque ligne du 
tableau correspond a une sequence donnee P/1 ou P/2 toutes deux relatives 
a une application P, ou une sequence J/1 ou J/2 toutes deux relatives & une 
autre application J. Dans differentes cases du tableau , le code de 
I'application est mentionn6 pour rappeler que la valeur consideree est 
relative a une application donn§e ; par exemple : 

♦ ADR-Cod-P : adresse de stockage relative a I'application P 

♦ j-cod : nombre d'octets relatif a I'application J 

Par ailleurs, le symbole « Cod » indique que la valeur consideree est 
relative £ une information de type « application » (programme ou donn6es 
du premier groupe), tandis que « Dat » indique que la valeur consideree est 
relative a une information de type « sequence » (donnees du second 
groupe) ; par exemple : 

• SGN-cod-P : signature d'informations (programme ou donnees ) relatives 
& I'application P 

• SGN-dat-J/2 : signature de donnees relatives a la sequence N°2 de 
20 I'application J 

Un exemple d&crira mieux le probleme pos6 et la fa$on de le 
resoudre en utilisant la presente invention. 

Le dispositif de traitement de I'information (carte 21 dans ce cas) 

25 vient de recevoir une commande de chargement initial de ('application P : 
application de paiement de type Porte-Monnaie Electronique (PME). Les 
informations applicatives stockees en memoire programmable sont le 
programme executable et les donnees relatives a I'application ; il n'y a pas 
encore de donnees evolutives correspondant a une sequence. Ces 

30 informations comprennent n-Cod octets stockes a partir d'une adresse 
ADR-Cod-P. L'indicateur de chargement est positionne « Charge ». En 



10 



15 
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plus des informations relatives au programme executable et aux donnees de 
I'application, les informations transmises lors de la commande contiennent 
un nombre d'octets de donnees evolutives « p-dat » relatives £ une 
sequence L Le tableau TAB_APPLI possede alors les valeurs suivantes : 

5 



Code 
application 

Num6ro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donnees evolutives 
des sequences notees € i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D6charge. 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/i 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


0 


p-dat 


0 


0 



tableau 11 : TAB APPLI 



Les transactions sont validees par un circuit electronique appele 
module de s6curit6. Ce module peut se situer soit dans le terminal lecteur de 

10 carte 20 de la figure 1, soit, si on desire un maximum de s§curite, dans un 
centre d'agrement bancaire qui peut se situer tres loin du terminal 20 . Une 
transaction de type P.M.E. se deroule en plusieurs etapes qui necessitent 
des communications entre la carte, le terminal et le module de s&curit6. 
L 'achat peut s'effectuer chez un commerpant dote d'un terminal avec 

15 module, mais il peut aussi etre fait au domicile du porteur de la carte dont le 
terminal n'est pas dot§ d'un module. 

La carte est sollicitee pour effectuer un achat par un ordre 
^initialisation d'une transaction. Le systeme d'exploitation de la carte 

20 reconnaTt un ordre de type applicatif ; il interroge alors son tableau 
TAB_APPLI. L'interrogation du tableau lui indique que I'application 
correspondant a I'ordre est bien charg6e et qu'aucune sequence n'a 6te 
allou6e. Le systeme d'exploitation initialise alors une s6quence en lui 
attribuant un numero , « 1 » par exemple. II alloue a cette sequence une 

25 place m6moire de « n-dat » octets, a partir de I'adresse ADR-Dat-P/1 . 
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L'indicateur de chargement correspondant a cette sequence est positionne 
sur « Charge ». Le tableau TAB_APPLI possede alors les valeurs suivantes 



Code 
application 
/ 


Informations relatives 
au programme executable et 
aux donnges de I'appticatton 


informations relatives 
aux donn£es 6vo!utives 
des sequences notfees « i 


» 


Num6ro 


adresse de 


nombre 


signature 


Charg6V 


adresse 


nombre 


signature 


Charge./ 


de 


stockage 


doctets 




D6charg£ 


de 


doctets 




D6charg£ 


sequence 










stockage 








P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Cftarg6 


ADR- 
Dat-P/1 


n-dat 


0 


Charg6 



5 tableau TAB_APPLI 1 2 

Puis, le systeme d'exploitation de la carte lance le programme 
applicatif en effectuant un saut a I'adresse ADR-Cod-P ; il specifie ladresse 
ADR-Dat-P/1 des donn6es temporaires a utiliser, ce qui permet a 

10 I'application de connaltre I'endroit ou sont memorisees les donndes de la 
sequence. Ces donnees sont, entre autres, le montant de la transaction, 
I'objet de la transaction, I'organisme vendeur et la date de la transaction. En 
revanche, une donnee telle que le solde du porte-monnaie §lectronique 
n'est pas une donn6e temporaire de sequence, car sa dur6e de vie d6passe 

15 celle dune sequence ; etant de type applicative, cette donnee est 
m6moris6e avec le programme de Tapplication. 

L'achat d'un premier produit est en cours : la carte envoie alors au 
lecteur 20 un message en vue d'obtenir une validation de la transaction 
20 auprfes d'un centre de paiement accessible par le r6seau. Cette 
communication peut durer un certain temps. En effet, les communications 
peuvent etre perturb6es et les donnees envoyees peuvent etre longuement 
analys6es par le centre d'agrement bancaire. Tout cela provoque un 
allongement de la dur6e globale de la transaction. Pendant ce temps, 
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I'utilisateur decide d'effectuer un second achat. La presente invention va 
permettre d'6viter d'attendre la fin de la premiere transaction pour 
commencer la seconde. 



5 Pour effectuer ce second achat, la carte est sollicit6e une 

seconde fois par un nouvel ordre d'initialisation d'une transaction. De meme 
que pr6c6demment, le systdme d'exploitation de la carte v6rifie que le 
programme executable de I'application PME est chargee en m6moire 
programmable. Cette verification s'effectue en interrogeant son tableau 

10 TAB_APPLI ; le systeme d'exploitation reconnait alors la presence du 
programme et d'une sequence (1) qui est en cours. Pour cela, il affecte a 
cette seconde execution un nouveau numero de s6quence (2) et initialise le 
tableau TAB_APPLI en rajoutant une nouvelle ligne a celui-ci. Puis, il verifie 
s'il existe suffisamment de place pour allouer dans la mdmoire 

15 programmable n-dat octets pour les informations de types donn§es non 
executables. Si la place est suffisante, une nouvelle adresse ADR-Dat-P/2 
est ddterminee et la seconde transaction peut §tre lancee. Le tableau 
TAB_APPLI possede les valeurs suivantes : 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evotutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharg 
e 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/1 


n-dat 


0 


Charge 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/2 


n-dat 


0 


Charge 



20 



tableau TAB APPLI 13 



Les deux transactions seront alors r6alisees en parallele dans la 
carte, sans faire appel au reseau. Le lecteur doit indiquer dans les 
commandes applicatives envoyees a la carte, de quelle transaction il s'agit. 
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Si la place est insuffisante. le systeme Sexploitation de la carte 
decide de d6charger uniquement les donnees §volutives correspondant a la 
premiere transaction (num§ro de sequence 1 ). II calcule alors la signature 
5 des dites donn6es de la premiere sequence « SGN-dat-P/1 », et I'inscrit 
dans le tableau TAB_APPLI. Les nouvelles donnees non ex6cutables 
pourront ainsi §tre a la meme place que les donnees dechargees, c'est-S- 
dire d une adresse commune aux deux s6quences et not6e ADR-Dat-P. 
Puis, la carte envoie au lecteur la commande suivante : 

10 



Ordre de d£chargement vers 


Carte C 


Appli P - Data - 


nombre 


« n_dat » 


le reseau 




numero de sequence 


n_dat 


octets de 






1 




donnees 



Cette commande est de structure identique a celle precitee, avec la 
difference suivante : la troisieme case contient un parametre sp§cifiant non 
seulement le code P de I'application , mais aussi le fait qu'il s'agit de 
15 donnees de type sequence (par le terme « Data »), et le numero 1 de la 
sequence concernee. 



20 



A la suite de cette commande, le tableau TAB_APPLI possede les 
valeurs suivantes : 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P1 


Decharge 


P(2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


0 


Charge 



tableau TAB APPL 



14 
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Suite a cette operation, la seconde transaction portant le numero 
de sequence 2 peut se poursuivre. Cette nouvelle transaction necessite 
aussi une validation de la part du centre de paiement : une demande est 
5 done 6mise vers le module de s§curit6. Supposons que la carte re$oive a ce 
moment un message de validation de la premiere transaction. Le systeme 
tf exploitation de la carte reconnait, £ Taide du num§ro de sequence, que ce 
message concerne une autre transaction que celle en cours et, par la lecture 
du tableau TAB_APPLI, il reconnalt la premiere transaction. Pour la traiter, il 
10 doit done charger les donnees non executables de la premiere transaction. 

Sachant que la place memoire est insuffisante pour les deux blocs 
de donnees, le systeme d'exploitation de la carte doit done decharger les 
donnees de la seconde transaction. II calcule alors la signature des dites 
15 donnees «c SGN-dat-P/2 » t et I'inscrit dans le tableau TAB_APPLI. Puis, la 
carte envoie au lecteur la commande suivante : 



ordre de deohargement vers 


carte c 


appli p - data - 


nombre 


«c n_dat » 


le reseau 




numero de sequence 
2 


n_dat 


octets de donnees 



Le tableau TAB_APPLI possede alors les valeurs suivantes : 

20 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donnees 6volutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge / 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge/ 
D6charg 

e 


P/1 


ADR- 
Cod-P 


rvcod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGM-dat- 
P/1 


Decharg 

e 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Decharg 

e 



tableau TAB APPLI 15 
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Le systeme Sexploitation de la carte envoie alors au lecteur la 
commande suivante : 



Commande de rechargement 


Carte C 


Appli P - Data - numero 


nombre 


ci partir du reseau 




de sequence 1 


n-dat 



Cette commande differe de la commande de rechargement d6j3 d6crite en 
ce que la troisieme case contient un parametre specifiant non seulement le 
code P de I'application , mais aussi le fait qu'il s'agit de donnees de type 
sequence (par le terme « Data »), et le numero 1 de la sequence concernee. 



Le lecteur re?oit la commande et la renvoie vers la banque de 
donn6e affectee notamment a la carte C. La banque de donnee recherche 
dans le fichier de cette carte, les n-dat octets de donn6es non ex£cutables 
relatives a I'application P, num§ro de sequence 1 . La banque de donn§es 
elabore le message suivant, qui est la r§ponse a la derniere commande de 
la carte ; cette reponse est transmise a la carte via le lecteur : 



Carte C 


Appli P - Data- num§ro 


n-dat 


n-dat octets de 




de sequence 1 




donn6es 



Cette commande differe de la reponse a une commande de rechargement 
d§ja decrite en ce que la deuxieme case contient un parametre specifiant 
non seulement le code P de Tapplication , mais aussi le fait qu'il s'agit de 
donnees de type s6quence (par le terme « Data »), et le numero 1 de la 
sequence concern6e. 

Le systeme d'exploitation de la carte peut effectuer une operation 
pr6liminaire selon laquelle il v6rifie que les codes C, P, le numero de 
sequence et la valeur n-dat repus t sont bien identiques a ceux de la 



2777673 



37 

commande emise precedemment. Si Pidentite est realisee, les n-dat octets 
regus sont m6moris6s £ partir de I'adresse ADR-dat-P lue dans le tableau 
TAB_APPLI . Une fois le dernier octet 6crit, le systeme d'exploitation 
recalcule la signature des donnees a I'aide d'un calcul cryptographique 
5 utilisant la valeur de ia cle SWAP. La signature recalcul6e est alors 
comparee a la valeur «c SGN-dat-P/1 » ecrite dans le tableau TAB_APPLI. Si 
les deux valeurs de signature ne seront pas egales, les donnees revues du 
r£seau sont consid§r6es comrnee non identiques & eel les d6chargees 
precedemment. II existe done un doute sur I'authenticite ou I'integrite des 
10 donnees revues. La carte renvoie au lecteur un message d'erreur indiquant 
la reception de donnees erronees au cours de la derniere operation de 
chargement, et I'impossibilite de continuer la transaction. 



Si les deux valeurs sont egales, les donnees revues sont 
15 consid§rees comme identiques & celles precedemment decharg6es par la 
carte la premiere transaction peut done continuer. Le systeme 
d'exploitation de la carte met ensuite a jour le tableau TAB_APPLI en 
positionnant Tindicateur des donnees de I'application P/1 a « Charge » : 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'apptication 


informations relatives 
aux donnees evolutrves 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/1 


Charge 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charg6 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Decharge 



20 



tableau 



AB APPLI 16 



La mise a jour du tableau TAB_APPLI etant terminee, le systeme 1 

i 

d'exploitation lance I'application P qui va continuer la premiere transaction. 
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La premiere transaction §tant termin6e, l'ex6cution du programme 
de I'application se termine par un retour au systeme d'exploitation gerant la 
memore virtuelle. Le systeme d'exploitation reconnalt alors la fin de la 
5 sequence «c 1 » et decide de liberer la place m§moire correspondant aux 
donn6es de la dite sequence. Pour cela, il efface les informations « adresse 
de stockage », « signature » et I'indicateur de chargement/d6chargement en 
les mettant d la valeur zero. 

10 Le tableau TAB APPLI a alors les valeurs suivantes : 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d* octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Decharge 



tableau TAB.APPLI 17 
Lorsque la carte re$oit la validation de la seconde transaction, le 



systdme Sexploitation de la carte reconnalt, a I'aide du numero de 
sequence, que ce message concerne une autre transaction qui n'est pas 
15 charg6e. La premiere transaction 6tant termin6e, les donndes non 
ex6cutables correspondantes ne sont plus utiles. II n'y a done pas lieu de les 
decharger. II suffit done de charger les donnees non executables 
correspondant a la seconde transaction. Le systeme d'exploitation envoie au 
lecteur la commande suivante : 



Commande de rechargement 


Carte 


Appli P - Data - numero 


nombre 


& partir du r£seau 


C 


de sequence 2 


n-dat 
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De meme que pour le chargement de la sequence 1, le lecteur 
re$oit la commande et la renvoie vers la banque de donnee. La banque de 
donnee recherche, dans le fichier de cette carte, les n-dat octets de donnees 
non ex£cutables relatives £ I'application P, numero de sequence 2. La 
banque de donn6es 6labore le message suivant qui est transmis a la carte 
via le lecteur : 



Carte C 


Appli P - Data- numero 


nombre 


n-dat octets de 




de s6quence 2 


n-dat 


donnees 



Le systeme d'exploitation de la carte peut effectuer une operation 
10 preliminaire selon laquelle il verifie les codes C, P, le numero de sequence, 
et la valeur n-dat re^us. Si la verification est conforme, les octets sont ecrits. 
Ensuite, le systeme d'exploitation calcule et verifie la signature des 
donnees. Si les deux valeurs sont egales, les donnees regues sont 
considerees comme identiques a cedes precedemment dechargees par la 
15 carte : la seconde transaction peut done continues Le syst&me d'exploitation 
met £ jour le tableau TAB_APPLI en positionnant I'indicateur de chargement 
de I'application P/2 £ « Charge » : 



Code 
application / 
Num6ro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees 6volutives 
des sequences not6es « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charg^./ 
D6charg6 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Charge 



tableau TAB APPL 



18 



20 La mise a jour du tableau TAB_APPLI etant termin6e, le systeme 

d'exploitation lance ('application P qui va continuer la seconde transaction. 
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La seconde transaction etant termin§e, le programme de 
I'application se termine par une instruction de retour au systeme 
d'exploitation gdrant la memoire virtuelle. Le systeme d'exploitation en 
5 deduit que la sequence « 2 » est termin6e ; la place memoire peut alors etre 
Iib£r6e. Pour cela, les emplacement, dans le tableau TAB_APPLI, de : 
« adresse de stockage », « signature » et I'indicateur de 
chargement/dechargement sont mis a z6ro. Le tableau prend les valeurs 
suivantes : 

10 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de ('application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


tableau 1 


fAB APPL 


19 



A ce stade, le systeme d'exploitation de la carte peut effacer 
entierement une ligne du tableau TAB_APPLI. La gestion des lignes du 
15 tableau TAB_APPLI s'effectue alors dynamiquement en fonction des 
besoins. 

Une autre m6thode statique pour g&rer le tableau est de d6cider 
une fois pour toutes le nombre de sequences maximum executables pour 
20 une application : soit « s » ce nombre. « s » est alors transmis tors de la 
commande de chargement initial d'application : le systeme d'exploitation 
reserve dans le tableau TAB_APPLI la place correspondant a ces « s » 
sequences. Prcnons par exemple pour s la valeur 2. 
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La commande de chargement de ('application K possede les 
valeurs suivantes : 



Ordre cle Chargement 


Carte C 


Appli K 


nombre n 


s=2 








n-cod 


n-dat 





Cette commande differe de celle d6crite precedemment en ce qu'elle inclut 
une cinquieme case definissant la valeur du parametre s. On notera qu'ici la 
commande specifie le nombre n-cod d'octets relatifs a I'application et 
envoyes par la commande, et le nombre n-dat d'octets relatifs a chaque 
10 sequence future et reserves a cet usage. En variante, le nombre n-dat 
d'octets peut ne pas etre transmis a ce stade, mais fourni plus tard au 
systeme Sexploitation de la carte par I'application qui y est chargee. 

A la suite de cette commande, le systeme d'exploitation met § jour 
15 le tableau TAB_ APPLI avec les valeurs suivantes : 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


K/1 


ADR- 
Cod-K 


n-cod 


SGN- 
cod-K 


Charge 


0 


n-dat 


0 


0 


K/2 


ADR- 
Cod-K 


n-cod 


SGN- 
cod-K 


Charge 


0 


n-dat 


0 


0 



tableau TAB APPL 



20 



20 L'application K peut maintenant etre executee : deux sequences 

sont possibles. 
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La carte peut parfaitement contenir de facon virtue lie plusieurs 
applications dotees chacune de plusieurs sequences. Par exemple, voici 
une configuration particuliere du tableau TAB_APPLI : 

5 



Code 
application / 
NJumero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d' octets 


signature 


Charge./ 
Decharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


K/1 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


Decharge 


0 


k-dat 


0 


0 


K/2 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


Decharge 


ADR- 
Dat-K/2 


k-dat 


SGN-dat- 
K/2 


Decharge 


K/1 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


Decharge 


ADR- 
Dat-K^ 


k-dat 


SGN-dat- 
K/3 


Charge 


J/1 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/1 


j-dat 


SGN-dat- 
J/1 


Charge 


J/2 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/2 


j-dat 


SGN-dat- 
J/2 


Decharge 


tableau " 


fAB APPL 


21 



Correspondant a cet exemple, la carte possede virtuellement 
deux applications notees : K et J. Le programme executable de Tapplication 

10 K n'est pas en zone de chargement ; trois sequences de cette application, 
not&es 1 ,2 et 3 ( peuvent s'ex6cuter en meme temps. La premiere sequence 
est terminee, les deux autres sont en cours d'execution. La sequence 2 est 
dechargee : il faudra done la recharger pour la terminer. De plus, pour 
terminer les sequences 2 et 3 t il faudra recharger le programme executable 

15 et les donnees de I'application K. 

Le programme executable de I'application J est en zone de 
chargement ; cette application peut ex6cuter en m§me temps deux 
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sequences, not6es 1 et 2, qui sont en cours d'execution. La sequence 2 est 
d§charg§e : il faudra la recharger pour la terminer. 

De cet exemple, on voit apparattre la n6cessite de bien gerer la 
5 place m6moire disponible. II faut occuper le plus possible la zone de 
chargement et ainsi 6viter le plus souvent les commandes de Dechargement 
et Rechargement 

Bien evidemment, Amelioration consistant a chiffrer les donn6es, 
10 en plus de les signer, lors du dechargement et a les dechiffrer lors du 
chargement/rechargement, peut s'appliquer a cette troisieme amelioration. 

Une am6lioration de la procedure de chargement initial d'une 
application en carte consiste S introduire dans la carte une signature des 
15 informations applicatives calculee a partir d'une cle de fournisseur 
d'application. Cette signature permet de s'assurer de Tintegrite des 
informations applicatives et d'authentifier Torigine de ces donnees 
applicatives. 

20 Le chargement initial selon l'am6lioration consiste a presenter la 

carte au fournisseur d'application. II est conseille d'effectuer cette operation 
dans les locaux du fournisseur d'application. Ce dernier introduit dans la 
carte sa cle de fournisseur, la signature des informations applicatives, et le 
code de I'application, « K » par exemple. Un porteur de la carte effectue une 

25 demande de chargement initial de I'application K. Cette demande, qui a et§ 
decrite prec6demment, peut §tre faite a son domicile. Une methode pour 
effectuer de fason s6curisee le chargement initial d'une application est 
decrite dans le document FR-A-2.748.134. 

30 Selon une variante de realisation de I'invention , les applications 

stockees en carte ne sont pas d§chargees dans une banque de donnees 
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distante, au travers d'un reseau : c'est le lecteur 20 de la figure 2 qui re?oit 
et stocke ces applications ; il possede alors a cet effet une memoire 
programmable non volatile dans laquelle sont stockees les applications. Les 
commandes de chargement et de dechargement sont inchangees. Cette 
5 variante est interessante lorsque la carte est introduite toujours dans le 
mfeme lecteur, par exemple un lecteur situe au domicile du porteur de carte. 

Une autre variante de realisation de I'invention utilise le lecteur de 
carte 40 et la carte £ puce 41 de la figure 4, dont les elements communs 

10 avec ceux de la figure 2 portent les memes references. La carte 41 se 
distingue de celle 21 de la figure 2 en ce qu'elle porte une piste optique 42, 
par exemple une piste a ecriture et lecture par rayon laser. Quant au lecteur 
de carte 40 t il se distingue de celui 20 en ce qu'il comporte un lecteur de 
piste optique 43, apte a lire et ecrire des informations sur la piste optique 42, 

1 5 relie au microprocesseur 2 et aux memoires 3,4. 

Selon Tinvention , la piste optique 42 est utilisee en tant que 
banque de donnees t au lieu de celles distantes 23 a 25 de la figure 1. En 
pratique, lors du dechargement d'une application depuis la carte 41 , la carte 

20 transmet la commande de dechargement au lecteur de carte 40. Le lecteur 
de piste 43 re?oit les informations de I'application et les ecrit sur la piste 
optique 42. Lors d'une commande de rechargement, le lecteur de carte 
active le lecteur de piste 43 pour qu'il preleve sur la piste optique 42 les 
informations de I'application : le lecteur de carte transmet ensuite ces 

25 informations au microprocesseur 9 de la carte pour que celui-ci les stocke 
dans la zone de chargement. Les commandes de chargement et de 
dechargement sont toutefois inchang6es. 

En variante, la piste optique est remplacee par un autre support d 
stockage de masse, par exemple une piste magn§tique. 

30 Dans les exemples de realisation precedents, on a considers que 

Tapplication 6tait chargee et exScutee dans la carte 21 de la figure 2, ou 
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dans le module correspondent 15 de la figure 3. Selon une autre variante de 
realisation moins pr6f6r§e de I'invention, c'est dans le terminal 20 de la 
figure 2, ou dans la partie du terminal 22 de la figure 3 coop6rant avec le 
module 15 que I'application est chargee et ex ecu tee, plus precisement dans 
5 la m6moire RAM de celui-ci, Le terminal possedera aussi une memoire 
programmable non volatile pour stocker I'application de fagon durable. 
Toutefois, avant tout dechargement de rapplication vers le reseau, le 
terminal transmettra rapplication a la carte 21 (ou au module 15 
correspondant) de fapon que celle-ci calcule la signature des informations 

10 de rapplication ; de meme, avant toute execution de rapplication dans le 
terminal apr6s son rechargement depuis le r6seau, le terminal effectuera la 
meme procedure pour qu'une nouvelle signature de rapplication soit 
calcul6e par la carte et comparee a la pr6cedente : la carte transmettra au 
terminal un resultat de cette comparaison et, seulement en cas d'identite, le 

15 terminal executera I'application rechargee. 

Dans les exemples de realisation precedents, on a decrit un 
dechargement duplications depuis un dispositif de traitement de 
reformation vers I'ext6rieur de celui-ci : dans le cas de la figure 2, la carte 

20 21 effectuait un dechargement vers le lecteur 20 ou les banques de donn§es 
23-25 de la figure 1 ; dans le cas de la figure 4, le dispositif de traitement de 
reformation constitue par le microprocesseur 9 et ses m6moires 10,14 
effectuait un dechargement vers la piste optique 42. Selon une autre 
variante de realisation de I'invention, un dispositif de traitement de 

25 reformation effectue un dechargement entre plusieurs memoires de ce 
dispositif. Par exemple, ce dispositif de traitement de reformation est 
constitue par la carte 21 de la figure 2 et le microprocesseur 9 decharge une 
application depuis sa m6moire RAM 14 vers sa m§moire non volatile 10. 

30 Par exemple, plusieurs applications K, J sont stockees dans la 

m6moire non volatile 10. Tout d'abord, I'application K est ex6cut6e. A cette 
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occasion, des informations de travail lt k relatives a 1'application K sont 
trait6es en memoire RAM, tandis qu'un programme de 1'application K reste 
en m6moire non volatile 10. Ces informations de travail comprennent 
notamment : 

5 - des variables de travail temporaires, intervenant dans des calculs ; 

- des variables de contexte, permettant a la carte de reprendre 
ult6rieurement une execution d'application interrompue ; 

- des sous-programmes. 

A un moment donne, la carte doit executer I'autre application J et, pour cela, 
10 charger des informations de travail Itj dans la memoire RAM. Si la carte 
constate que I'espace libre dans la memoire RAM est insuffisant pour 
recevoir les informations de travail Itj , elle decide de stopper I'exfecution de 
1'application K et de decharger les informations de travail It* de 1'application 
K dans sa memoire non volatile 10. Puis elle execute 1'application J en 
15 chargeant les informations de travail Itj associees en memoire RAM. Apr6s 
execution de I'application J, la carte reprend l'ex6cution de I'application K, a 
I'endroit ou celle-ci a ete interrompue, en chargeant a nouveau les 
informations de travail lt k en memoire RAM. 



20 Dans cette derniere variante de Tinvention, les commandes de 

chargement et de dechargement ne sont pas utilisees, puisque le dispositif 
de traitement de reformation concerne n'a pas £ avertir un dispositif externe 
pour effectuer les operations de chargement et dechargement de ses 
memoires. II possfede encore un tableau TAB_APPLI, mais celui-ci est 

25 simplifie par rapport au tableau 2 precite : le parametre « signature des 
informations » est supprime. En effet, les informations ne sortant pas du 
dispositif de traitement de reformation, elles ne risquent pas d'etre alterees 
durant leur dechargement. 
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REVENDICATIONS 

1. Dispositif de traitement de reformation comprenant des moyens de 
traitement de Information (9) et des moyens de memorisation de I'information 

5 principaux (10,14), caracteris£ en ce que les moyens de traitement 
comprennent : 

- des moyens pour detecter, au cours du fonctionnement du dispositif 
de traitement de reformation, que les moyens de memorisation principaux 
(10,14) contiennent une quantite d'informations telle qu'un stockage 

10 supplemental d'un ensemble donne d'informations a stocker (J) n'est pas 
possible ; 

- des moyens pour selectionner, dans les moyens de memorisation 
principaux, un ensemble d'informations a decharger (K), dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 

15 espace suffisant pour autoriser le stockage dudit ensemble d'informations a 
stocker ; 

- des moyens pour decharger Pensemble d'informations a decharger 
(K) dans des moyens de memorisation secondares (23 a 25 ; 42 ; 53) , dans 
le cas ou lesdits moyens de memorisation secondares ne contiennent pas 

20 ledit ensemble d'informations a decharger ; et 

- des moyens pour stocker dans les moyens de memorisation 
principaux (10,14) Tensemble d'informations £ stocker (J). 

2. Dispositif selon la revendication 1, qui comprend un tableau de 
25 chargement (TAB_APPLI) stocke dans les moyens de memorisation 

principaux et incluant un indicateur de stockage indiquant, pour au moins un 
ensemble d'informations , si celui-ci est stock6 ou non dans les moyens de 
memorisation principaux, de sorte que , lorsque les moyens de traitement (9) 
doivent avoir acc6s audit ensemble d'informations , ils consultent ledit 
30 indicateur de stockage : et 
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- dans un premier cas ou I'indicateur de stockage indique que 
I'ensemble d' informations est stocke , les moyens de traitement accedent £ 
celui-ci ; ou 

- dans un second cas ou I'indicateur de stockage indique que 
5 I'ensemble d'informations n'est pas stocke , les moyens de traitement 

envoient aux moyens de memorisation secondaires (23 a 25 ; 42 ; 53) une 
commande de chargement de cet ensemble d'informations. 

3. Dispositif selon la revendication 2, dans lequel I'indicateur de 
10 stockage comporte un 6tat « charg6 » indiquant que I'ensemble 

d'informations correspondant a ete charge dans le dispositif de traitement de 
Tinformation a partir des moyens de memorisation secondaires (23 a 25 ; 42 ; 
53), et un etat « decharge » indiquant que I'ensemble d'informations a et6 
decharge par le dispositif de traitement de Tinformation dans les moyens de 
15 memorisation secondaires. 

4. Dispositif selon la revendication 1, qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 
principaux (10,14) et incluant un indicateur de modification indiquant, pour au 

20 moins un ensemble d'informations dont une premiere version a ete charg§e 
dans le dispositif de traitement de Tinformation a partir des moyens de 
memorisation secondaires (23 d 25 ; 42 ; 53), si cette premiere version a ete 
modifiee dans le dispositif de traitement de Tinformation. 

25 5. Dispositif selon la revendication 1 , qui stocke au moins un ensemble 

d'informations en deux parties, a savoir un sous-ensemble d'informations 
d'application (p-cod) contenant un programme et des donnees g6n6rales de 
fonctionnement d'une application, et un sous-ensemble d'informations de 
sequence (p-dat) contenant des donnees particulieres definissant une 

30 session particuliere de fonctionnement de Tapplication , et qui comprend des 
moyens pour d£tecter que plusieurs ensembles d'informations poss6dent un 
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m&me sous-ensemble d'informations d'application (p-cod) et des sous- 
ensembles ^informations de sequence respectifs differents (p-dat), de sorte 
qu'il ne stocke dans les moyens de memorisation principaux (10,14) qu'une 
fois ledit sous-ensemble d'informations d'application et qu'il associe a celui-ci 
5 chacun desdits sous-ensembles d'informations de sequence. 

6. Dispositif selon la revendication 5 P qui comprend : 

- des moyens pour detecter, au cours de son fonctionnement, que les 
moyens de memorisation principaux (10 t 14) contiennent une quantite 

10 d'informations telle que le stockage supplemental d'un sous-ensemble 
d 1 informations de sequence (p-dat) & stocker t associe a un sous-ensemble 
d'informations d'application (p-cod) deja stocke, n'est pas possible ; 

- des moyens pour selectionner, dans les moyens de memorisation 
principaux, un sous-ensemble d'informations de sequence a decharger, 

15 associe au meme sous-ensemble d'informations d'application , dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 
espace suffisant pour autoriser le stockage dudit sous-ensemble 
d'informations de sequence a stocker ; 

- des moyens pour decharger ce sous-ensemble dans lesdits moyens 
20 de memorisation secondares (23 a 25 ; 42 ; 53), dans le cas ou lesdits 

moyens de memorisation secondares ne contiennent pas ledit sous- 
ensemble d'informations de sequence a d6charger ; et 

- des moyens pour stocker dans les moyens de memorisation 
principaux le sous-ensemble d'informations de sequence a stocker. 

25 

7. Dispositif selon la revendication 5, qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 
principaux et incluant, pour chaque sous-ensemble d'informations 
d'application stocke, un nombre maximum (s) de sequences associees, 

30 pouvant etre stock6es dans les moyens de memorisation principaux. 
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8. Dispositif selon la revendication 1, qui comprend des moyens pour 
recharger dans les moyens de memorisation principaux (10,14) un ensemble 
d' informations pr6alablement d6charge dans les moyens de memorisation 
secondares (23 a 25 ; 42 ; 53). 

5 

9. Dispositif selon la revendication 8, qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 
principaux (10,14) et incluant, pour au moins un ensemble d' informations (K) 
traite par le dispositif, une premiere signature (SGN-K) de cet ensemble 

10 d'informations calculee par les moyens de traitement (9) avant le 
d6chargement 6ventuel de I'ensemble d'information, avec une cle de 
signature (SWAP) stockee dans les moyens de memorisation principaux, les 
moyens de traitement 6tant agences pour calculer une seconde signature de 
I'ensemble d'informations recharge, pour comparer cette seconde signature 

15 avec la premiere, pour valider le rechargement de I'ensemble d'informations 
dans le cas ou les deux signatures sont identiques, et pour invalider le 
rechargement de I'ensemble d'informations dans le cas ou les deux 
signatures sont differentes. 

20 10. Procede de stockage d'informations dans un dispositif de 

traitement de information comprenant des moyens de traitement de 
I'information (9) et des moyens de memorisation de I'information principaux 
(10,14) , et dans des moyens de memorisation secondares associ6s (23 a 25 
; 42 ; 53), caract§ris§ en ce qu'il comprend les etapes consistant d : 

25 - d§tecter, au cours du fonctionnement du dispositif de traitement de 

information, que les moyens de memorisation principaux contiennent une 
quantity d'informations telle qu'un stockage supplemental d'un ensemble 
donne d'informations & stocker (J) n'est pas possible ; 

- selectionner, dans les moyens de memorisation principaux, un 

30 ensemble d'informations a decharger (K), dont le dechargement peut Iib6rer 
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dans les moyens de memorisation principaux un espace suffisant pour 
autoriser le stockage dudit ensemble d'informations a stocker ; 

- decharger I'ensemble d'informations a decharger (K) dans les 
moyens de memorisation secondares, dans le cas ou lesdits moyens de 

5 memorisation secondares (23 a 25 ; 42 ; 53) ne contiennent pas ledit 
ensemble d'informations £ decharger ; et 

- stocker dans les moyens de memorisation principaux (10,14) 
I'ensemble d'informations a stocker (J). 

10 11. Proc6de selon la revendication 10, qui comprend les Stapes 

consistant a : 

- detecter, au cours du fonctionnement du dispositif de traitement de 
rinformation, que les moyens de memorisation principaux (10,14) contiennent 
une quantite d'informations telle qu'un stockage supplemental d'un 

15 ensemble donne d'informations prealablement decharge est possible ; 

- recharger dans les moyens de memorisation principaux ledit 
ensemble d'informations decharge. 

12. Proc6d6 selon la revendication 10, qui comprend les etapes 
20 consistant a : 

- detecter, au cours du fonctionnement du dispositif de traitement de 
rinformation, que les moyens de memorisation principaux (10,14) contiennent 
une quantite d'informations telle qu'un stockage supplementaire d'un 
ensemble donne d'informations prealablement decharge (K) n'est pas 

25 possible ; 

- selectionner, dans les moyens de memorisation principaux, un 
ensemble d'informations a decharger (J), dont le dechargement peut Iib6rer 
dans les moyens de memorisation principaux un espace suffisant pour 
autoriser le stockage dudit ensemble d'informations prealablement decharge ; 

30 - decharger I'ensemble d'informations a decharger (J) dans les moyens 

de memorisation secondares (23 a 25 ; 42 ; 53), dans le cas ou lesdits 
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moyens de memorisation secondares ne contiennent pas ledit ensemble 
d'informations a decharger ; et 

- recharger dans les moyens de memorisation principaux ledit 
ensemble d'informations prealablement decharge (K). 

13. Procede selon la revendication 10, dans lequel lesdits moyens de 
memorisation secondares comprennent une banque de donn6es (23-25) 
distante du dispositif de traitement de r information et reliee a celui-ct par un 
reseau de transmission de donnees (26). 

14. Procede selon la revendication 10, dans lequel lesdits moyens de 
memorisation secondares appartiennent a un second dispositif de 
traitement de reformation (20) cooperant avec ledit dispositif de traitement 
de reformation (21). 

15. Procede selon la revendication 10, dans lequel lesdits moyens de 
memorisation secondares (42;53) appartiennent audit dispositif de 
traitement de Information. 
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